---
title: "nginx的常用配置"
categories:
- devops
tags:
---

<div id="content">
<div id="table-of-contents">
<h2>Table of Contents</h2>
<div id="text-table-of-contents">
<ul>
<li><a href="#org376544e">指令</a>
<ul>
<li><a href="#org3c22639">proxy_pass</a></li>
<li><a href="#orgfa02254">location</a></li>
</ul>
</li>
</ul>
</div>
</div>
<div class="outline-2" id="outline-container-org376544e">
<h2 id="org376544e">指令</h2>
<div class="outline-text-2" id="text-org376544e">
</div>
<div class="outline-3" id="outline-container-org3c22639">
<h3 id="org3c22639">proxy_pass</h3>
<div class="outline-text-3" id="text-org3c22639">
<p>
<b>Syntax</b>: proxy_pass URL;
</p>
<p>
A request URI is passed to the server as follows: 
</p>
<ul class="org-ul">
<li>如果URL部分是URI，则reqeust url中匹配的部分被替换</li>
</ul>
<blockquote>
<p>
If the proxy_pass directive is specified with a URI, then when a request is passed to the server, the part of a normalized request URI matching the location is replaced by a URI specified in the directive: 
</p>
</blockquote>
<div class="org-src-container">
<pre class="src src-conf"><span style="font-weight: bold; text-decoration: underline;">location /name/</span> {
    proxy_pass http://127.0.0.1/remote/;
    <span style="font-weight: bold; font-style: italic;"># </span><span style="font-weight: bold; font-style: italic;">http://127.0.0.1/remote/是URI，如果请求 /name/user/abc，则后端接受到的是/remote/user/abc</span>
}
</pre>
</div>
<ul class="org-ul">
<li>如果URL部分不是URI，则原样转发</li>
</ul>
<blockquote>
<p>
If proxy_pass is specified without a URI, the request URI is passed to the server in the same form as sent by a client when the original request is processed, or the full normalized request URI is passed when processing the changed URI: 
</p>
</blockquote>
<div class="org-src-container">
<pre class="src src-conf"><span style="font-weight: bold; text-decoration: underline;">location /some/path/</span> {
    proxy_pass http://127.0.0.1; <span style="font-weight: bold; font-style: italic;"># </span><span style="font-weight: bold; font-style: italic;">request for /some/path/ab/cd -&gt; /some/path/ab/cd</span>
}
</pre>
</div>
</div>
</div>
<div class="outline-3" id="outline-container-orgfa02254">
<h3 id="orgfa02254">location</h3>
<div class="outline-text-3" id="text-orgfa02254">
<blockquote>
<p>
<a href="http://www.cnblogs.com/aiguang/p/3571207.html">http://www.cnblogs.com/aiguang/p/3571207.html</a>
</p>
</blockquote>
<p>
<b>syntax</b>: location [=|~|~*|^~|@] <i>uri</i> { … }
</p>
<p>
location后的几个符号，大致分为两类：
</p>
<ul class="org-ul">
<li>普通(literal)匹配
<ul class="org-ul">
<li>无任何前缀，普通的</li>
<li>= 严格匹配，不仅阻止nginx继续匹配正则，也阻止nginx使用最大匹配，只要请求与=后面定义的路径相同，这个块立即被应用</li>
<li>^~ 告诉nginx不匹配正则，仅使用普通匹配的最大匹配结果</li>
<li>@ 用来定义“Named Location ”的（你可以理解为独立于“普通location （location using literal strings ）”和“正则location （location using regular expressions ）”之外的第三种类型），这种“Named Location ”不是用来处理普通的HTTP 请求的，它是专门用来处理“内部重定向（internally redirected ）”请求的。注意：这里说的“内部重定向（internally redirected ）”或许说成“forward ”会好点，以为内internally redirected 是不需要跟浏览器交互的，纯粹是服务端的一个转发行为。</li>
</ul></li>
<li>正则表达式(regular)匹配
<ul class="org-ul">
<li>~ for case sensitive matching</li>
<li>~* for case insensitive matching</li>
</ul></li>
</ul>
<p>
匹配的一般规则是：先匹配普通location，得到一个临时结果。然后匹配正则表达式，如果正则表达式中能找到匹配的，则使用正则表达式的结果。否则作用普通匹配结果。
特殊规则：普通location中存在一些方法，能够停止后面的匹配。
</p>
<ol class="org-ol">
<li><b>普通location，使用最大匹配</b> ，例如：</li>
</ol>
<pre class="example">
location /prefix/mid/ {} # A
location /prefix/ {} # B
</pre>
<p>
对于HTTP 请求 {% raw %} /prefix/mid/t.html {% endraw %} ，前缀匹配的话两个location 都满足，但是根据规则 <b>the most specific match</b> ，于是选的是A
普通location 先匹配，而且选择了最大前缀匹配后，不能就停止后面的匹配，最大前缀匹配只是一个临时的结果，nginx 还需要继续检查正则location。
</p>
<ol class="org-ol">
<li>正则表达式 <b>正则location 在配置文件中的顺序匹配</b> 。只要匹配到一条正则location ，就停止进行后面的正则匹配。</li>
</ol>
<p>
如果继续搜索的“正则location ”也有匹配上的，那么“正则location ”覆盖 “普通location ”的最大前缀匹配；但是如果“正则location ”没有能匹配上，那么就用“普通location ”的最大前缀匹配结果。
</p>
<p>
特殊规则：
</p>
<ul class="org-ul">
<li>在“普通location ”前面加上^~告诉Nginx ：匹配到了“普通location ”后，不再需要继续匹配“正则location ”了</li>
<li>= 也能阻止继续搜索正则location，不同点是^~依然遵守“最大前缀”匹配规则，然而=不是“最大前缀”，而是必须是严格匹配（exact match ）。</li>
</ul>
<p>
例如“location / {} ”和“location = / {} ”的区别：
</p>
<ul class="org-ul">
<li>location / {} 遵守普通location 的最大前缀匹配，由于任何URI 都必然以“/ ”根开头，所以对于一个URI ，如果有更specific 的匹配，那自然是选这个更specific 的，如果没有，“/ ”一定能为这个URI 垫背（至少能匹配到“/ ”），也就是说“location / {} ”有点默认配置的味道</li>
<li>location = / {} 遵守的是“严格精确匹配exact match ”，也就是只能匹配 <a href="http://host:port/">http://host:port/</a> 请求，同时会禁止继续搜索正则location 。因此如果我们只想对“GET / ”请求配置作用指令，那么我们可以选“location = / {} ”这样能减少正则location 的搜索，因此效率比“location / {}” 高（注：前提是我们的目的仅仅只想对“GET / ”起作用）。</li>
</ul>
<p>
“最大前缀”匹配恰好就是一个“严格精确（exact match ）”匹配，照样会停止后面的搜索。原文字面意思是：只要遇到“精确匹配exact match ”，即使普通location 没有带“= ”或“^~ ”前缀，也一样会终止后面的匹配。例如：
</p>
<pre class="example">
location /exact/match/test.html { 配置指令块1} # exact match
location /prefix/ { 配置指令块2}
location ~ \.html$ { 配置指令块3} 

GET /prefix/index.html 会被匹配到指令块3
GET /exact/match/test.html 会匹配到指令块1 
</pre>
<p>
总结指令的顺序：
</p>
<ol class="org-ol">
<li>Directives with the "=" prefix that match the query exactly. If found, searching stops.</li>
<li>All remaining directives with conventional strings. If this match used the "^~" prefix, searching stops.</li>
<li>Regular expressions, in the order they are defined in the configuration file.</li>
<li>If #3 yielded a match, that result is used. Otherwise, the match from #2 is used.</li>
</ol>
</div>
</div>
</div>
</div>
<div class="status" id="postamble">
<p class="author">Author: gdme1320</p>
<p class="validation"><a href="http://validator.w3.org/check?uri=referer">Validate</a></p>
</div>
